Mapping selective DSCP values to GTP-U

ABSTRACT

An apparatus and a method are provided by which a packet is received, a service identification in the packet is detected, it is decided based on the detected service identification whether a tunnel protocol extension header is to be generated or not, and, when the tunnel protocol extension header is to be generated, the tunnel protocol extension header is generated, the received packet is encapsulated with the generated tunnel protocol extension header and the encapsulated packet is forwarded.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of co-pending U.S. patent applicationSer. No. 14/388,069 filed on Sep. 25, 2014, which is the national stageapplication based on PCT International Application No.PCT/EP2012/055440, filed on Mar. 27, 2012. The entire disclosures ofthese earlier applications are hereby incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to apparatuses, methods and a computerprogram product for mapping selective DSCP values to GTP-U.

RELATED BACKGROUND ART

The following meanings for the abbreviations used in this specificationapply:

-   APN Access Point Name-   BSC Base Station Controller-   BSSGP Base Station Subsystem GPRS Protocol-   DSCP DiffServ Code Point-   GERAN GERAN GSM/EDGE Radio Access Network-   GGSN Gateway GPRS Support Node-   GPRS General Packet Radio Service-   GSM Global System for Mobile communications-   GTP GPRS Tunnelling Protocol-   GTP-U GTP-User plane.-   GW Gateway-   Internet Protocol-   PDN Packet Data Network-   PDN-GW Packet Data Network Gateway (also P-GW)-   PDP Packet Data Protocol-   PMIP Proxy Mobile IP-   S-GW Serving Gateway-   TDF Traffic Detection Function-   UE User Equipment

3GPP is currently working on “Service Identification for RRCimprovements in GERAN” (SIRIG). It is envisioned that the core networkinforms the GERAN radio network when downlink IP packets relating tospecific applications are detected via deep packet inspection within thecore network. The GERAN radio network will use this information toconfigure radio bearers according to the needs of the detectedapplications, e.g. by assigning a suitable number of timeslots for thebandwidth requirements of the application.

Within the core network, the deep packet inspection will either beperformed by a GGSN/PDN-GW or by a standalone Traffic Detection Function(TDF) (see TS 23.203).

It has been agreed within 3GPP CT4 as a working assumption that theGGSN/PDN-GW using the GPRS Tunnelling Protocol (GTP) (TS 29.060) willtransfer the information towards the SGSN within a new extension headerwithin the GTP user plane packets used to transfer the user planerelating to the specific application. If a standalone TDF is used, itwill transfer the information to the GGSN/PDN-GW as DiffServ Code Point(DSCP) marks within the IP header of the inspected user plane packetsand the GGSN/PDN-GW provides an interworking to GTP-U.

A GGSN using Proxy Mobile IP (PMIP) will transfer the information to theServing-GW as DSCP marks within the IP header of the inspected userplane packets, and the Serving-GW will forward the information towardsthe SGSN within a new extension header within the GTP user plane packetsused to transfer the user plane.

The SGSN will transfer the information on to the GERAN BSC using anextension of the Base Station Subsystem GPRS Protocol (BSSGP) (TS48.018).

3GPP is also studying improvements for IP traffic handling for otherradio networks than GERAN and might thus decide to use the new CTP-Uheader extension towards other radio networks in the future.

The DSCP header is a mandatory part of the IP header and always present.It is normally used for requesting priority treatment within IP routers.The new GTP-U header extension, as described above, will increase theoverall size of a GTP-U package by 8 byte and thus lead to extrabandwidth requirements where GTP is used. If the DSCP IP header isalways interworked, the new GTP-U extension header will also be suppliedfor user plane packets that do not relate to applications that requirespecial treatment, which leads to an unnecessary waste of resources.

SUMMARY OF THE INVENTION

Embodiments of the present invention address this situation and aim toreduce the use of resources in connection with the new extension header.

According to a first aspect of the present invention an apparatus isprovided which comprises

at least one interface unit configured to provide connection to at leastone network, and

a processor configured

to receive a packet via the at least one interface unit,

to detect a service identification in the packet,

to decide based on the detected service identification whether a tunnelprotocol extension header is to be generated or not, and,

when the tunnel protocol extension header is to be generated, togenerate the tunnel protocol extension header, to encapsulate thereceived packet with the generated tunnel protocol extension header andto forward the encapsulated packet.

According to a second aspect of the present invention, an apparatus isprovided which comprises

an interface unit configured to provide connection to a network, and

a processor configured

to receive a packet via the interface unit,

to detect whether the packet relates to a specific application, and,

when it is detected that the packet relates to the specific application,to insert a service identification in the packet (based on theapplication, or,

when it is detected that the packet does not relate to a specificapplication, to insert a default service identification in the packet.

According to a third aspect of the present invention, a method isprovided which comprises

receiving a packet from at least one network,

detecting a service identification in the packet,

deciding, based on the detected service identification, whether a tunnelprotocol extension header is to be generated or not, and,

when the tunnel protocol extension header is to be generated, generatingthe tunnel protocol extension header, encapsulating the received packetwith the generated tunnel protocol extension header and forwarding theencapsulated packet.

According to a fourth aspect of the present invention, a method isprovided which comprises

receiving a packet,

detecting whether the packet relates to a specific application, and,

when it is detected that the packet relates to the specific application,inserting a service identification in the packet based on theapplication, or,

when it is detected that the packet does not relate to a specificapplication, inserting a default service identification in the packet.

According to a fifth aspect of the present invention, a system isprovided which comprises a gateway including an apparatus according tothe first aspect or modifications thereof, and a transport detectionfunction including an apparatus according to the second aspect ormodifications thereof, wherein the processor of the gateway isconfigured to receive the packets sent from the transport detectionfunction.

According to a sixth aspect of the present invention, a computer programproduct is provided which comprises code means for performing a methodaccording to any one of the third to fourth aspects when run on aprocessing means or module. Thus, according to embodiments of thepresent invention, a tunnel protocol extension header is generated onlywhen necessary, so that the network load and required bandwidth for thecorresponding packets can be reduced.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features, details and advantages will becomemore fully apparent from the following detailed description ofembodiments of the present invention which is to be taken in conjunctionwith the appended drawings, in which:

FIG. 1 shows a basic structure of a gateway according to an embodimentof the present invention,

FIG. 2 shows a basic operation of a gateway according to an embodimentof the present invention,

FIG. 3 shows a basic structure of a TDF according to an embodiment ofthe present invention,

FIG. 4 shows a basic operation of a TDF according to an embodiment ofthe present invention,

FIG. 5 shows an example arrangement of entities with a separate TDFaccording an embodiment of the present invention, and

FIG. 6 shows an example arrangement of entities according an embodimentof the present invention, wherein the TDF is integrated in a PDN-GW.

DETAILED DESCRIPTION OF EMBODIMENTS

In the following, description will be made to embodiments of the presentinvention. It is to be understood, however, that the description isgiven by way of example only, and that the described embodiments are byno means to be understood as limiting the present invention thereto.

FIG. 1 shows a gateway 1 as an example for an apparatus according to amore general embodiment of the present invention. The apparatus may be anetwork control node, e.g., a gateway such as a GGSN/PDN GW or aServing-GW or may be only a part thereof, for example. The gateway 1comprises a processor 11 and one or several interface unit(s) 12. Theinterface unit(s) 12 are configured to provide connection to one orseveral network(s), wherein the interface unit(s) 12 may be furtherconfigured to receive packets containing service identification such asDSCP and/or to send tunnel packets such as GTP-U user plane packet. Theprocessor 11 is configured to carry out procedures which are illustratedin the flow chart of FIG. 2. Optionally, the gateway 1 may also comprisea memory 13 for storing data and programs, by means of which theprocessor 11 may carry out its corresponding functions.

FIG. 2 illustrates a basic operation as carried out by the gateway 1 ofFIG. 1, for example. In step S11, a packet is received (e.g., via theinterface unit 12). In step S12 a DCSP value (as an example for aservice identification) is detected in the packet, e.g., the packet isevaluated whether such a value is present. In step S13, it is decidedbased on the detected DCSP value whether a tunnel protocol extensionheader (e.g., GTP-U extension header) is to be generated or not. If thetunnel protocol extension header is to be generated (YES in S13), theprocess proceeds to step S14, in which the tunnel protocol extensionheader is generated and the received packet is encapsulated with thegenerated tunnel protocol extension header. In step S16, theencapsulated packet is forwarded.

In case it is decided in step S13 that no tunnel protocol extensionheader is to be generated (NO in S13), no extension header is generated(S15) and the packet is forwarded without such a header in S16.

In addition, according to another embodiment, in step S13 the accesspoint name (APN) may be considered to decide whether a tunnel protocolextension header is to be generated or not. For certain APNs, no tunnelextension header is generated. For other APNs, the received DSCP valueis considered to decide whether a tunnel protocol extension header is tobe generated or not.

Hence, according to certain embodiments of the present invention, thetunnel protocol extension header is generated only when it is needed,e.g., when an particular service or application requires a specifictreatment, which is indicated by using the service indication (e.g.,DCSP value).

FIG. 3 shows a TDF (transport detection function) 1 as an example for anapparatus according to a more general embodiment of the presentinvention. The apparatus may be TDF or may be only a part thereof, forexample. The TDF 2 comprises a processor 21 and one or several interfaceunit(s) 22. The interface unit(s) 22 are configured to provideconnection to one or several network(s), wherein the interface unit(s)12 may be further configured to receive packets and/or to send packetscontaining service identification such as DSCP. The processor 21 isconfigured to carry out procedures which are illustrated in the flowchart of FIG. 4. Optionally, similar as in case of the gateway shown inFIG. 1, the TDF 2 may also comprise a memory 23 for storing data andprograms, by means of which the processor 21 may carry out ascorresponding functions.

FIG. 4 illustrates a basic operation as carried out by the TDF 2 of FIG.3, for example. In step S21, a packet is received (e.g., via theinterface unit 22). In step S22, the packet is evaluated, i.e., it isdetected whether the packet relates to a specific application, and, whenit is determined in step S23 (YES in S23) that the packet relates to thespecific application, a DCSP value (as an example for a serviceidentification) is inserted in the packet based on the application instep S24. When it is detected that the packet does not relate to aspecific application (NO in S23), a default DCSP value (as an examplefor a default service identification) is inserted in the packet in S25.In step S16, the encapsulated packet is forwarded, for example to thegateway 1 shown in FIG. 1.

Hence, according to certain embodiments of the present invention, TDFalways inserts a DSCP value, even when there is no specific applicationdetected. In this way, an apparatus such as the gateway 1 can reliablydecide whether to generate the tunnel protocol extension header for thispacket or not.

The specific application described above may be a predefined applicationwhich requires special treatment such as providing a specific bandwidth,a specific data rate, a specific quality of service class, resourcereservation for a specific duration, and/or a specific routing for thepacket.

Thus, according to a more detailed embodiment of the present invention,a network control node such as a GGSN/PDN GW or Serving Gateway decidesbased on the value of the DSCP within a received IP packet whether togenerate an GTP-U extension header for the GTP-U packet it uses toencapsulate and forward that IP packet.

In the following, implementation examples according to some embodimentsof the present invention are described.

According to an embodiment, the GGSN/PDN GW or Serving Gateway uses anoperator-configurable list of DCSP values to be interworked to GTP-Uextension header to decide whether to generate a GTP-U extension header.For each such DSCP value to be interworked, the content of the GTP-Uextension header to be supplied is also stored.

The GGSN may store several such operator configurable lists and selectthe appropriate list based on the Access Point Name (APN) negotiated fora Packet Data Protocol (PDP) session toward a user equipment (UE). Thisallows to handle scenarios where the downlink traffic towards a GGSN isreceived from several different IP networks (depending on APN) and/oronly for some users a TDF is inserted.

According to a further embodiment, in order to avoid that theinformation which application specific handling is used by GERAN becomesvisible to the UE, the GGSN may replace received DSCP values with adefault DSCP value in the IP header of the IP packet encapsulated withinGTP-U if the GGSN/PDN GW or Serving Gateway decides to provide the newGTP-U extension header.

Downlink IP packets may be received from an external network and DSCPvalues in this networks might be used for other purposes. To guaranteethat no DSCP marks from entrusted sources in external networks areforwarded to the GGSN/PDN GW, the TDF is configured to perform DSCPmarking for all passed IP packets. If the TDF does not identify anapplication requiring special treatment in the GERAN for a downlink IPpacket, the TDF marks that IP packet with a default configured DSCPvalue that the GGSN does not interwork to the new GTP-U headerextension. If the TDF identifies an application requiring specialtreatment in the GERAN for a downlink TP packet, the TDF marks that IPpacket with a special configured DSCP value that the GGSN interworks tothe new GTP-U header extension; the TDF is configured with an applicableDSCP value for each applications it can identify that requires specialhandling in the GERAN.

FIG. 5 shows an arrangement of entities and transfer of Downlink IPpackets in case PDN-GW uses GTP according to a further embodiment of thepresent invention.

As shown in FIG. 5, a PDN-GW/GGSN 52 (in the following referred to asGGSN only) receives packets from a first network, IP network A, and froma second network, IP network B. The IP network A comprises a TDF 51.

The TDF 51 supplies IP DSCP markings for all IP packets it passes. Itinspects the IP packets using deep packet inspection. For IP packet 2,the TDF discovers a particular application that requires a special DSCPmarking “b”. For IP packet 1, the TDF does not discover a particularapplication and thus applies a configured default DSCP marking “a”.

The GGSN 52 is configured per APN whether to map received DSCP valuesinto GTP-U header extensions. The IP network the GGSN interconnects withalso depends on the APN.

For the APN corresponding to IP network A the GGSN 52 is configured tomap received DSCP values into GTP-U header extensions. For each IPpackage received in such an APN the GGSN then checks the received DSCPvalue to decide whether to generate a GTP-U header extension with anapplication ID.

For IP packet 2, the GGSN decides to generate a GTP-U extension headerwith Application ID “B” because there is a configured mapping for thereceived DSCP mark “b” towards the Application Id “B”. For IP packet 1,the GGSN decides not to generate a GTP-U extension header with anApplication ID because there is no configured mapping for the receivedDSCP mark “a”.

For the APN corresponding to IP network B the GGSN is configured not tomap received DSCP values into GTP-U header extensions. It thus does notgenerate an GTP-U extension header for IP packet 3 received from IPnetwork B.

Thus, the GGSN 52 forwards packet 1 using GTP-U without the extensionheader, packet 2 using GTP-U with the extension header (indication AppId B), and packet 3 using GTP-U without the extension header to an SGSN53. The SGSN 53 forwards the packets to a BSC 54 using BSSGP, whereinonly packet 2 comprises App Id B.

The BSC 54 configures radio for connection to a UE 56 via a base station55 according to App Id B only. That is, radio resources are configuredsuch that they are suited for the application indicated by App Id B.Hence, packet 2 can be sent to the UE. For packets 1 and 3, however, nospecific treatment is necessary, so that in connection with thesepackets no specific radio configuration is necessary.

FIG. 6 shows an arrangement of entities and transfer of Downlink IPpackets in case PDN-GW uses PMIP according to another embodiment of thedescription.

In the example of FIG. 6, the TDF is integrated within the PDN-GW 61.However, the TDF could also be separate from the PDN-GW and would thenbe located on the core network side of the PDN-GW (e.g., then the TDFcan be located in the IP network A, similar as shown in FIG. 5). ThePDN-GW could then be configured to pass DSCP marks received from trustednetworks with a separate TDF, and not to pass DSCP marks received fromother networks but replace them with a configured default DSCP mark.

The PDN-GW 61 receives packets from the IP network A. The TDF suppliesIP DSCP markings for all IP packets it passes. It inspects the IPpackets using deep packet inspection. For IP packet 2, the TDF discoversa particular application that requires a special DSCP marking “b”. ForIP packet 1, the TDF does not discover a particular application and thusapplies a configured default DSCP marking “a”.

The Serving-GW 62 is configured per APN and/or per interconnected PDN-GWwhether to map received DSCP values into GTP-U header extensions.

In this example, the Serving-GW 62 is configured to map received DSCPvalues into GTP-U header extensions for the APN corresponding to IPnetwork A. For each IP package received in such an APN the Serving-GW 62checks the received DSCP value to decide whether to generate a GTP-Uheader extension with an application ID.

For IP packet 2, the Serving-GW decides to generate a GTP-U extensionheader with Application ID “B” because there is a configured mapping forthe received DSCP mark “b” towards the Application Id “B”. For IP packet1, the Serving-GW decides not to generate a GTP-U extension header withan Application ID because there is no configured mapping for thereceived DSCP mark “a”.

The remaining procedure is similar to that described above in connectionwith FIG. 5, that is, the Serving-GW 62 forwards the packets to an SGSN63, which forwards the packets to a BSC 64. The BSC supplies the packetsto a base station 65, which forwards the packets to a UE 66.

It is noted that the embodiments and the present invention in general isnot limited to the specific examples given above.

For example, in the above embodiments, the apparatus (e.g., gateway 1shown in FIG. 1) deciding to generate the tunnel protocol extensionheader was described as a part of a gateway such as a GGSN/PDN-GW orServing-GW. However, the apparatus may also be provided as a stand-alonenetwork element, or it may be provided in another suitable networkcontrol node.

Furthermore, as also described already above, the apparatus (e.g., TDF 2shown in FIG. 2) placing the service indications into the packets may beprovided as a stand-alone network element (as shown in FIG. 5, forexample), but can also be provided in another network element such asPDN-GW (as shown in FIG. 6, for example).

In some of the above embodiments, GTP was used as a tunnel protocol.However, the invention is not limited to this, and also other suitableprotocols may be applied, as along as an extension header can becreated.

Furthermore, in some of the above embodiments, DCSP was used as aservice indication. However, the invention is not limited to this andother kinds of service indications may be applied, provided that thegateway 1 (or a similar apparatus) is able to detect and understand sucha service indication.

Hence, according to certain embodiments of the present invention, anapparatus and a method are provided by which a packet is received, aservice identification in the packet is detected, it is decided based onthe detected service identification whether a tunnel protocol extensionheader is to be generated or not, and, when the tunnel protocolextension header is to be generated, the tunnel protocol extensionheader is generated, the received packet is encapsulated with thegenerated tunnel protocol extension header and the encapsulated packetis forwarded.

According to a further aspect of the present invention an apparatus isprovided which comprises

means for receiving a packet from at least one network,

means for detecting a service identification in the packet,

means for deciding, based on the detected service identification,whether a tunnel protocol extension header is to be generated or not,and,

means for, when the tunnel protocol extension header is to be generated,generating the tunnel protocol extension header, encapsulating thereceived packet with the generated tunnel protocol extension header andforwarding the encapsulated packet.

According to another aspect of the present invention an apparatus isprovided which comprises

means for receiving a packet,

means for detecting whether the packet relates to a specificapplication, and,

means for, when it is detected that the packet relates to the specificapplication, inserting a service identification in the packet based onthe application, or, when it is detected that the packet does not relateto a specific application, inserting a default service identification inthe packet.

It is to be understood that any of the above modifications can beapplied singly or in combination to the respective aspects and/orembodiments to which they refer, unless they are explicitly stated asexcluding alternatives.

For the purpose of the present invention as described herein above, itshould be noted that

-   -   an access technology via which signaling is transferred to and        from a network element may be any technology by means of which a        network element or sensor node can access another network        element or node (e.g. via a base station or generally an access        node). Any present or future technology, such as WLAN (Wireless        Local Access Network), WiMAX (Worldwide Interoperability for        Microwave Access), LTE, LTE-A, UMTS, HSPA, Bluetooth, Infrared,        and the like may be used; although the above technologies are        mostly wireless access technologies, e.g. in different radio        spectra, access technology in the sense of the present invention        implies also wired technologies, e.g. IP based access        technologies like cable networks or fixed lines but also circuit        switched access technologies; access technologies may be        distinguishable in at least two categories or access domains        such as packet switched and circuit switched, but the existence        of more than two access domains does not impede the invention        being applied thereto,    -   usable communication networks, stations and transmission nodes        may be or comprise any device, apparatus, unit or means by which        a station., entity or other user equipment may connect to and/or        utilize services offered by the access network; such services        include, among others, data and/or (audio-) visual        communication, data download etc.;    -   a user equipment or communication network element (station) may        be any device, apparatus, unit or means by which a system user        or subscriber may experience services from an access network,        such as a mobile phone or smart phone, a personal digital        assistant PDA, or computer, or a device having a corresponding        functionality, such as a modem chipset, a chip, a module etc.,        which can also be part of a UE or attached as a separate element        to a UE, or the like;    -   method steps likely to be implemented as software code portions        and being run using a processor at a network element or terminal        (as examples of devices, apparatuses and/or modules thereof, or        as examples of entities including apparatuses and/or modules        therefore), are software code independent and can be specified        using any known or future developed programming language as long        as the functionality defined by the method steps is preserved;    -   generally, any method step is suitable to be implemented as        software or by hardware without changing the idea of the        invention in terms of the functionality implemented;    -   method steps and/or devices, units or means likely to be        implemented as hardware components at the above-defined        apparatuses, or any module(s) thereof, (e.g., devices carrying        out the functions of the apparatuses according to the        embodiments as described above, eNode-B etc. as described above)        are hardware independent and can be implemented using any known        or future developed hardware technology or any hybrids of these,        such as MOS (Metal Oxide Semiconductor), CMOS (Complementary        MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter        Coupled Logic), TTL (Transistor-Transistor Logic), etc., using        for example ASIC (Application Specific IC (Integrated Circuit))        components, FPGA (Field-programmable Gate Arrays) components,        CPLD (Complex Programmable Logic Device) components or DSP        (Digital Signal Processor) components;    -   devices, units or means (e.g. the above-defined apparatuses, or        any one of their respective means) can be implemented as        individual devices, units or means, but this does not exclude        that they are implemented in a distributed fashion throughout        the system, as long as the functionality of the device, unit or        means is preserved;    -   an apparatus may be represented by a semiconductor chip, a        chipset, or a (hardware) module comprising such chip or chipset;        this, however, does not exclude the possibility that a        functionality of an apparatus or module, instead of being        hardware implemented, be implemented as software in a (software)        module such as a computer program or a computer program product        comprising executable software code portions for execution being        run on a processor;    -   a device may be regarded as an apparatus or as an assembly of        more than one apparatus, whether funtionally in cooperation with        each other or functionally independently of each other but in a        same device housing, for example.

It is noted that the embodiments and examples described above areprovided for illustrative purposes only and are in no way intended thatthe present invention is restricted thereto. Rather, it is the intentionthat all variations and modifications be included which fall within thespirit and scope of the appended claims.

1. An apparatus comprising an interface unit configured to provideconnection to a network, and a processor configured to receive a packetvia the interface unit, to detect whether the packet relates to aspecific application, and when it is detected that the packet relates tothe specific application, to insert a service identification in thepacket based on the application, wherein a list including a plurality ofspecific applications and service indications associated with each ofthe specific applications is provided, and the processor is configuredto insert the service identification in the packet by referring to thelist.
 2. The apparatus according to claim 1, wherein the specificapplication is a predefined application which requires special treatmentsuch as providing a specific bandwidth, a specific data rate, a specificquality of service class, resource reservation for a specific duration,and/or a specific routing for the packet.
 3. The apparatus according toclaim 1, wherein the apparatus is provided in transport detectionfunction network element or in a gateway.
 4. A method comprisingreceiving a packet, detecting whether the packet relates to a specificapplication, and, when it is detected that the packet relates to thespecific application, inserting a service identification in the packetbased on the application, wherein a list including a plurality ofspecific applications and service indications associated with each ofthe specific applications is provided, and the method further comprisesinserting the service identification in the packet by referring to thelist.
 5. The method according to claim 4, wherein the specificapplication is a predefined application which requires special treatmentsuch as providing a specific bandwidth, a specific data rate, a specificquality of service class, resource reservation for a specific duration,and/or a specific routing for the packet.